Methods for risk management in payment-enabled mobile device

ABSTRACT

A payment-enabled mobile device such as a “smart phone” incorporates risk management features applicable when used for a contactless payment transactions. In some embodiments, a mobile device processor includes a non-volatile memory storing a first counter and an associated first accumulator used for financial risk management purposes, and storing a second counter and an associated second accumulator used for enforcing a cardholder verification requirement, and storing a payment application program. In some embodiments, features govern when cardholder verification is required for consummation of the current transaction, and such features may be configurable by the payment card account issuer and/or the user of the mobile device.

CROSS-REFERENCE TO RELATED APPLICATION

This application claims priority to and the benefit of U.S. patentapplication Ser. No. 12/915,550 filed on Oct. 29, 2010, and claims thebenefit of U.S. Provisional Patent Application No. 61/258,759 filed onNov. 6, 2009, which patent applications are incorporated by referenceherein.

BACKGROUND

Payment cards such as credit or debit cards are ubiquitous. For decades,such cards have included a magnetic stripe on which the relevant accountnumber is stored. To consummate a purchase transaction with such a card,the card is swiped through a magnetic stripe reader that is part of apoint of sale (POS) terminal. The reader reads the account number fromthe magnetic stripe. The account number is then used to route atransaction authorization request that is initiated by the POS terminal.The authorization request is routed from the merchant's acquiringfinancial institution (“acquirer”) to a server computer operated by oron behalf of the issuer of the payment account. The issuer's servercomputer provides a response to the authorization request. If theresponse indicates that the issuer has authorized the transaction, thetransaction is consummated at the point of sale. Later the transactionis cleared for settlement via the acquirer and the issuer.

More recently, cards that incorporate an integrated circuit (IC) havebeen utilized as payment cards. In various embodiments, IC payment cardsmay be interfaced to a POS terminal via contacts on the card. During apurchase transaction, the payment card account number and otherinformation may be uploaded from the IC payment card to the POS terminalvia the IC card contacts and a contact card reader that is included inthe POS terminal. Authorization and clearing may then proceed insubstantially the same manner as for a transaction initiated with a magstripe payment card (putting aside additional security measures that maybe implemented by using the processing capabilities of the IC paymentcard).

In other IC payment card systems, the exchange of information betweenthe card and the POS terminal proceeds via wireless RF (radio frequency)communications. These wireless communication payment cards are sometimesreferred to as “contactless” payment cards. One example of a contactlesspayment card standard is referred to in the United States by the brandname “PayPass” and was established by MasterCard InternationalIncorporated, the assignee hereof. It has also been proposed to usewireless exchanges of information via NFC (Near Field Communication) forpayment applications.

Conventional payment system purchase transactions that require real-timeon-line communication with the account issuer—for the purpose ofauthorization or (in a “one message” system) for immediate chargeagainst the customer's account—are sometimes referred to as “on-line”transactions. However, some payment card account issuers are willing toallow certain classes of transactions (e.g., transactions for smallmonetary amounts) to be consummated for later clearing without obtainingauthorization from the issuer's computer while the transaction ispending between the merchant and the customer. In these transactions,the merchant's device (POS system) is not required to engage incommunications with the issuer's computer while the transaction istaking place, and the transactions are accordingly sometimes referred toas “offline” transactions. For these transactions, issuers typicallyconsider the risk of a relatively small loss to fraud as beingoutweighed by the need to speed up the transaction for the convenienceof the customer and the merchant.

It has been proposed that the capabilities of a contactless payment cardbe incorporated into a mobile telephone, thereby turning the mobiletelephone into a contactless payment device. Typically a mobiletelephone/contactless payment device includes integrated circuitry withthe same functionality as the RFID (radio frequency identification) ICof a contactless payment card. In addition, the mobiletelephone/contactless payment device includes a loop antenna that iscoupled to the payment-related IC for use in sending and/or receivingmessages, via short-distance wireless communications, in connection witha transaction that involves contactless payment.

Contactless payment devices in other form factors, such as key fobs,wristwatches, wristbands and stickers, have also been proposed. It hasalso been proposed that mobile devices other than mobile telephones—suchas PDAs with mobile communication capabilities—may also incorporatecontactless payment functionality.

In general, issuers of payment card accounts are concerned with thesubject of “risk management”. Risk management refers to the balancing ofthe risk of loss due to fraud or over-spending with the costs andinconvenience that may be required for measures that may be undertakento deter or prevent fraudulent transactions or over-spending. Theabove-noted practices relating to requiring real-time authorization forsome transactions while not requiring such authorization for othertransactions are examples of applications of the principles of riskmanagement. The present inventors have now devised additional novel riskmanagement techniques (described below) that are especially suitable forapplication with payment-enabled mobile devices.

BRIEF DESCRIPTION OF THE DRAWINGS

Features and advantages of some embodiments of the present invention,and the manner in which the same are accomplished, will become morereadily apparent upon consideration of the following detaileddescription of the invention taken in conjunction with the accompanyingdrawings, which illustrate preferred and exemplary embodiments and whichare not necessarily drawn to scale, wherein:

FIG. 1 is a block diagram that illustrates a system provided inaccordance with aspects of the present invention.

FIG. 2 is a block diagram that illustrates communication aspects of apurchase transaction that utilizes a payment-enabled mobile telephone.

FIG. 3 is a block diagram that illustrates physical aspects of thetransaction shown in FIG. 2.

FIG. 4 is a block diagram that illustrates an example embodiment of apayment-enabled mobile telephone as shown in FIGS. 1-3.

FIG. 5 is a block diagram that illustrates aspects of software and/orfirmware programs that control the payment-enabled mobile telephone ofFIG. 4.

FIG. 5A is a block diagram that illustrates functionality provided inthe payment-enabled mobile telephone relative to risk managementtechniques according to aspects of the present invention.

FIG. 6 is a block diagram representation of a typical POS terminal thatmay embody aspects of the present invention.

FIG. 7 is a block diagram representation of a server computer operatedby a payment card account issuer and depicted as part of the system ofFIG. 1.

FIG. 8 schematically illustrates a process for personalizing apayment-enabled mobile telephone.

FIGS. 9A and 9B together form a flow chart that illustrates a processthat may be performed in the system of FIG. 1 according to aspects ofthe present invention.

FIGS. 10 and 11 are example screen displays that may be provided by thepayment-enabled mobile telephone in connection with transactionsperformed in accordance with the process of FIGS. 9A and 9B.

FIG. 12 is a flow chart that illustrates another process that may beperformed in the system of FIG. 1 according to aspects of the presentinvention.

FIGS. 13-15 are further flow charts that illustrate processes that maybe performed in the system of FIG. 1 according to aspects of the presentinvention.

FIGS. 16 and 17 are example screen displays that may be provided by thepayment-enabled mobile telephone in connection with transactionsperformed in accordance with the process of FIG. 15.

FIGS. 18 and 19 are additional flow charts that illustrate processesthat may be performed in the system of FIG. 1 according to aspects ofthe present invention.

FIGS. 20A and 20B are flow charts that illustrate aspects of theinvention relating to possible configurations of a payment applicationprogram in a payment-enabled mobile telephone.

FIG. 20C is a table that illustrates specific example configurations ofthe payment application program in accordance with aspects of thepresent invention.

FIGS. 21-23 are further flow charts that illustrate processes that maybe performed in the system of FIG. 1 according to aspects of the presentinvention.

DETAILED DESCRIPTION

In general, and for the purpose of introducing concepts of embodimentsof the present invention, a payment-enabled mobile device and a POSterminal (and/or other components of a payment system) interact in waysthat enhance risk management techniques. In one example, thepayment-enabled device may need to be tapped on the POS terminal readercomponent either once or twice depending on one or more attributes ofthe transaction. If two taps are required, the payment-enabled mobiledevice may require the user to acknowledge the transaction details ormay require the user to enter a personal identification number(PIN)—before the second tap—again depending on one or more attributes ofthe transaction.

FIG. 1 is a block diagram that illustrates a system 100 provided inaccordance with aspects of the present invention.

The system 100 includes a payment-enabled mobile telephone 102. Thepayment-enabled mobile telephone 102 may be operable as a mobiletelephone, while also being able to perform functions of a contactlesspayment card and also embodying risk management functionality asprovided in accordance with aspects of the present invention and asdescribed below. Further details of the payment-enabled mobile telephone102 are described below in conjunction with FIG. 4 and other drawings.

The system 100 further includes a proximity reader component 104associated with a POS terminal 106. The proximity reader component 104and the POS terminal 106 may be substantially or entirely conventionalin their hardware aspects and may also incorporate conventional softwarecapabilities as well as additional software capabilities provided inaccordance with the present invention and described below.

As will be recognized by those who are skilled in the art, the proximityreader component 104 and the POS terminal 106 may be located at thepremises of a retail store and operated by a sales associate of theretailer for the purpose of processing retail transactions. Thepayment-enabled mobile telephone 102 is shown in FIG. 1 to beinteracting with the proximity reader component 104 and the POS terminal106 for the purpose of executing such a purchase transaction. Somedetails of the POS terminal 106 are presented below in conjunction withFIG. 6.

A computer 108 operated by an acquirer (acquiring financial institution)is also shown as part of the system 100 in FIG. 1. The acquirer computer108 may operate in a conventional manner to receive an authorizationrequest for the transaction from the POS terminal 106. The acquirercomputer 108 may route the authorization request via a payment system110 to the server computer 112 operated by the issuer of the paymentcard account that is available for access by the payment-enabled mobiletelephone 102. Also in a conventional manner, the authorization responsegenerated by the payment card issuer server computer 112 may be routedback to the POS terminal 106 via the payment system 110 and the acquirercomputer 108.

The payment system 110 may be entirely or substantially conventional;one example of a suitable payment system is the well-known Banknetsystem operated by MasterCard International, Inc., which is the assigneehereof.

Details of the payment card issuer server computer 112 are providedbelow in conjunction with FIG. 7. However, to briefly anticipate laterdiscussion, the payment card issuer server computer 112 may be operatedby or on behalf of a financial institution (“FI”; not separately shown)that issues payment card accounts to individual users. In many respects,the payment card issuer server computer 112 may perform conventionalfunctions, such as (a) receiving and responding to requests forauthorization of payment card account transactions to be charged topayment card accounts issued by the FI; and (b) tracking and storingtransactions and maintaining account records. In addition, as describedin detail below, the payment card issuer server computer 112 mayfunction in accordance with aspects of the present invention.

The components of the system 100 as depicted in FIG. 1 are only thosethat are needed for processing a single transaction. Those who areskilled in the art will recognize that a practical embodiment of thesystem 100 may process many purchase transactions (includingsimultaneous transactions) and may include a considerable number ofpayment card issuers and their computers, a considerable number ofacquirers and their computers, and numerous merchants and their POSterminals and associated proximity reader components. The system mayalso include a very large number of payment card account holders, whocarry payment-enabled mobile devices and/or payment cards (includingcontactless payment cards and/or magnetic stripe cards).

It should also be understood that the payment-enabled mobile telephone102 is operable as a conventional mobile telephone forcommunication—both voice and data—over a conventional mobiletelecommunications network, which is not depicted in the drawing. Thus,the payment-enabled mobile telephone 102 is in communication in aconventional manner with a mobile network operator (“MNO”—also notshown). An over-the air communication channel (not shown in FIG. 1)between the payment-enabled mobile telephone 102 and the payment cardissuer server computer 112 (or a related computer) may be establishedfrom time to time for purposes such as personalization (as discussedbelow) of the payment application program in the payment-enabled mobiletelephone 102; for updates to the personalization; for loading/reloadingpre-paid/pre-authorized funds in connection with the payment applicationprogram; and/or for resetting a counter or accumulator that isestablished in the payment-enabled mobile telephone 102 for riskmanagement purposes.

FIG. 2 schematically illustrates some communication aspects of a typicalpurchase transaction in which the payment-enabled mobile telephone 102is used. The POS terminal is represented at block 106, and the proximityreader component is represented by block 104. Wireless communicationbetween the payment-enabled mobile telephone 102 and the proximityreader component 104 is indicated at 202. The wireless communication 202may be conducted in accordance with one or more standard protocols, suchas “EMV Contactless” and/or NFC all of which are well known to those whoare skilled in the art.

FIG. 3 schematically illustrates some physical aspects of the purchasetransaction. As in FIG. 3, the POS terminal 106 and its associatedproximity reader component 104 are shown. The payment-enabled mobiletelephone 102 is also shown in proximity to the proximity readercomponent 104. In a common manner of initiating the wirelesscommunication depicted in FIG. 2, the user of the payment-enabled mobiletelephone 102 briefly taps the payment-enabled mobile telephone 102 at aparticular location on the proximity reader component 104. The locationon the proximity reader component 104 at which the payment-enabledmobile telephone 102 is to be tapped may be indicated to the user by astandard logo affixed to the proximity reader component 104, such as the“PayPass” logo.

FIG. 4 is a block diagram representation of the payment-enabled mobiletelephone 102, as provided in accordance with aspects of the presentinvention. The payment-enabled mobile telephone 102 may be conventionalin its hardware aspects. For example, the payment-enabled mobiletelephone 102 may resemble, in most of its hardware aspects and many ofits functions, a conventional “smart phone” such as the “iPhone”marketed by Apple Inc.

The payment-enabled mobile telephone 102 may include a conventionalhousing (indicated by dashed line 402 in FIG. 4) that contains and/orsupports the other components of the payment-enabled mobile telephone102. The housing 402 may be shaped and sized to be held in a user'shand, and may for example fit in the palm of the user's hand.

The payment-enabled mobile telephone 102 further includes conventionalcontrol circuitry 404, for controlling over-all operation of thepayment-enabled mobile telephone 102. For example, the control circuitry404 may include a conventional processor of the type designed to be the“brains” of a smart phone.

Other components of the payment-enabled mobile telephone 102, which arein communication with and/or controlled by the control circuitry 404,include: (a) one or more memory devices 406 (e.g., program and workingmemory, etc.); (b) a conventional SIM (subscriber identification module)card 408; (c) a keypad 412 for receiving user input; and (d) aconventional display component 410 for displaying output information tothe user. For present purposes the keypad 412 will be understood toinclude, e.g., a conventional 12-key telephone keypad, in addition toother buttons, switches and keys, such as a conventionalrocker-switch/select key combination, soft keys, and send and end keys.

As is now frequently the case with smart phones, the functionalityrepresented by the display 410 and keypad 412 may be provided in anintegrated manner via a conventional touch screen, which is notindicated in the drawing apart from blocks 410 and 412.

The payment-enabled mobile telephone 102 also includes conventionalreceive/transmit circuitry 416 that is also in communication with and/orcontrolled by the control circuitry 404. The receive/transmit circuitry416 is coupled to an antenna 418 and provides the communicationchannel(s) by which the payment-enabled mobile telephone 102communicates via the mobile telephone communication network (not shown).The receive/transmit circuitry 416 may operate both to receive andtransmit voice signals, in addition to performing data communicationfunctions.

The payment-enabled mobile telephone 102 further includes a conventionalmicrophone 420, coupled to the receive/transmit circuitry 416. Ofcourse, the microphone 420 is for receiving voice input from the user.In addition, a loudspeaker 422 is included to provide sound output tothe user, and is coupled to the receive/transmit circuitry 416.

In conventional fashion, the receive/transmit circuitry 416 operates totransmit, via the antenna 418, voice signals generated by the microphone420, and operates to reproduce, via the loudspeaker 422, voice signalsreceived via the antenna 418. The receive/transmit circuitry 416 mayalso handle transmission and reception of text messages and other datacommunications via the antenna 418.

The payment-enabled mobile telephone 102 may also include a paymentcircuit 424 and a loop antenna 426, coupled to the payment circuit 424.The payment circuit 424 may include functionality that allows the mobiletelephone 102 to function as a contactless payment device. In someembodiments, the payment circuit 424 includes a processor (notseparately shown) and a memory (not separately shown) that is coupled tothe processor and stores program instructions for controlling theprocessor. Although shown as separate from the main processor 404, thepayment circuit 424 and/or its processor component may be integratedwith the main processor 404. Thus, the functionality represented by thepayment circuit may be largely implemented with a payment applicationprogram (not shown in FIG. 4), that controls a portion of the operationsof the main processor 404. The control aspect of the payment circuit 424may also control a transceiver (also represented by block 424) whichhandles the short-distance wireless communications via the antenna 426.In accordance with conventional practices, and in accordance with someembodiments, the mobile telephone may include a so-called “secureelement” (not separately shown), which may be incorporated with thepayment circuit 424, the main processor 404 or the SIM card 408. As isfamiliar to those who are skilled in the art, the secure element may beconstituted with a small processor and volatile and nonvolatile memory(NVM; block 428) that are secured from tampering and/or reprogramming bysuitable measures. The secure element may, for example, manage functionssuch as storing and reading out a payment card account number, andcryptographic processing.

As will be seen, the NVM 428 may store counter values and/or accumulatorvalues that the payment-enabled mobile telephone 102 uses with respectto risk management activities.

The payment circuit 424 (to the extent it is a separate processor frommain processor 404) may be in communication with the control circuitry404 via a data communication connection 430.

FIG. 5 is a block diagram that schematically illustrates some softwareaspects of the payment-enabled mobile telephone 102. Block 502 in FIG. 5represents the payment application program that was referred to above inconjunction with FIG. 4. In many respects the payment applicationprogram may be conventional, but in other respects it may implement riskmanagement techniques as described below.

In some embodiments, the payment application program may be operable ineither one of two modes, namely a payment mode and a management mode.The payment application may be in the payment mode when it is engaged inan exchange of communications with the proximity reader component 104during a payment or purchase transaction; otherwise, it may be in themanagement mode. The latter mode may be used for activities in which thepayment application is being configured, or is accepting input from theuser (e.g., for cardholder verification), for top-ups/reloads, etc.

Block 504 in FIG. 5 represents user interface software that controls aportion of the operations of the main processor 404. For example, theuser interface software 504 may receive input from, and controldisplaying of information on, the touch screen that was referred toabove in conjunction with FIG. 4. The payment application program 502and the user interface software 504 may interact with each other toallow the user to control and/or respond to the payment functionality ofthe payment-enabled mobile telephone 102. The interaction between thepayment application program 502 and the user interface software 504 maybe mediated by a software program 505 that may be referred to as a“midlet”. The midlet 505 may interact with the user through the userinterface (display/keyboard/touchscreen) via the user interface softwareto receive input such as ACK signals and/or PIN entry as describedbelow. The midlet 505 may also interact with the card account issuerserver computer via an over-the-air interface to reset one or morecounters and/or accumulators. Moreover the midlet 505 may instruct thepayment application program 502 as to how the payment applicationprogram is to be configured, in a management mode of the paymentapplication program. Such instructions from the midlet 505 to thepayment application program 502 may be based on information providedover the air to the midlet 505 from the issuer server computer.

Block 506 in FIG. 5 represents one or more flags that may be selectivelyset and/or cleared by the payment application program in connection withimplementation of the risk management techniques described below.

The payment application program 502, the user interface software 504 andthe risk management flags 506 depicted in FIG. 5 may each be stored inone or more of the memory devices referred to above in conjunction withFIG. 4. Such memory devices are collectively represented by block 508 inFIG. 5.

FIG. 5A is a block diagram that illustrates functionality provided inthe payment application program 502 relative to risk managementtechniques according to aspects of the present invention.

In FIG. 5A, block 520 represents software capabilities in thepayment-enabled mobile telephone 102 that allow the payment-enabledmobile telephone 102 to perform one or more cardholder verificationmethods (CVM). The cardholder verification methods may entail (asdescribed below) prompting the user to enter a PIN, receiving the PINdigits as entered by the user, and verifying that the entered PIN digitsmatch the PIN as previously stored in the payment-enabled mobiletelephone 102. In addition or alternatively, other CVM techniques may beemployed in the payment-enabled mobile telephone 102, such as biometrictechniques that may include fingerprint reading or facial recognition.

Block 522 represents configuration flags or the like, input into thepayment-enabled mobile telephone 102 by the payment card account issuerand/or the user to select one or more configuration options provided bythe mobile CVM software 520. Examples of issuer- and/or user-selectableconfiguration options will be provided below.

Block 524 represents risk management software capabilities that may beimplemented in the payment-enabled mobile telephone 102 apart fromconventional issuer-centric risk management techniques. The “card-based”risk management software 524 may operate based on inputs such as thestate of one or more transaction counters/accumulators maintained in thepayment-enabled mobile telephone 102, security settings as input fromthe payment card account issuer, current transaction data (amount oftransaction and/or the identification of the currency in which thetransaction is being conducted), and results of CVM activities in thepayment-enabled mobile telephone 102 relative to the currenttransaction.

Block 526 represents card verification results (CVR) which cumulateresults of evaluation of one or more risk policies applicable to theoperation of the payment application program. Among the risk policiesinvolved there may be results of mobile cardholder verification (e.g.,was the PIN entered correctly; was the ACK signal provided). Other riskpolicy results represented by the card verification results 526 mayinclude whether one or more counters and accumulators exceededapplicable limits, whether the number of PIN re-tries was exceeded, etc.The card verification results 526 may be stored in one or more registersthat serve as a bridge between the mobile CVM software 520 and the cardrisk management software 524. For example, the card verification resultsmay include one or more flags to indicate whether required riskmanagement inputs have been provided by the user as needed for thecurrent transaction.

Block 528 represents software for controlling the above-referencedtransaction counters/accumulators. Block 530 represents a control maskthat is configurable by the issuer to select risk management policies tobe applied in the payment-enabled mobile telephone 102. Block 532represents a flag to indicate whether the user has duly acknowledged(ACK'd) the transaction information for the current transaction. Block534 represents a flag to indicate whether the user has duly entered avalid PIN for the current transaction.

Block 508 again represents one or more of the memory devices that arepart of the payment-enabled mobile telephone 102.

FIG. 6 is a block diagram of a typical embodiment of the POS terminal106 depicted in FIG. 1 (and incorporating the proximity reader component104—represented as an RFID/NFC terminal in FIG. 6). In some embodiments,the POS terminal 106 may be largely or entirely conventional in itshardware aspects. Nevertheless, the POS terminal 106 may be programmedin accordance with the aspects of the present invention to providefunctionality as described herein.

The POS terminal 106 may include a processing element (or elements) suchas the processor 602 shown in FIG. 6. The processor 602 may for examplebe a conventional microprocessor, and may operate to control the overallfunctioning of the POS terminal 106. The POS terminal 106 may alsoinclude conventional peripheral components, in communication with and/orcontrolled by the processor 602, such as: (a) a keypad 604 for receivinginput from the human operator of the POS terminal; (b) a barcode reader606 for reading product barcodes from products brought to the terminalfor purchase; (c) a cash drawer 608 for storing cash received fromcustomers; (d) a magnetic stripe reader 610 for reading payment cardaccount numbers and related information from magnetic stripe paymentcards; (e) one or more displays 612 for providing output (e.g.,identifying products presented for purchase and their prices, indicatingsales tax due, indicating transaction subtotals and totals, etc.); (f) aprinter 614 for printing out sales receipts; (g) the above-mentionedproximity reader component 104, for exchanging wireless short rangecommunications/near field communications (NFC) with contactless paymentcards and/or with mobile telephones equipped with contactless paymentdevice capabilities; and (h) a communication controller 618 for allowingthe processor 602, and hence the POS terminal 106 to engage incommunication over data networks with other devices (e.g., a merchantprocessing system (not shown), and an acquirer (FIG. 1) or itstransaction processor (not shown)). (In some embodiments, at least oneof the displays 612 may be a touch screen, so as to provide an inputfunction as well as an output function.)

In addition, the POS terminal 106 may include one or more memory and/ordata storage devices (indicated collectively at 620), which may compriseany combination of one or more of a hard disk drive, RAM (random accessmemory), ROM (read only memory), flash memory, etc. The memory/datastorage device(s) 620 may store software and/or firmware that programsthe processor 602 and the POS terminal 106 to perform functionality asdescribed herein. Further, the POS terminal may include one or morehousings (not shown) which contain and/or support one or more of theother components shown in FIG. 6.

FIG. 7 is a block diagram that illustrates an embodiment of the paymentcard issuer server computer 112 (FIG. 1).

The payment card issuer server computer 112 may be conventional in itshardware aspects but may be controlled by software to cause it tofunction as described herein. For example, the payment card issuerserver computer 112 may be constituted by conventional server computerhardware.

The payment card issuer server computer 112 may include a computerprocessor 700 operatively coupled to a communication device 701, astorage device 704, an input device 706 and an output device 708.

The computer processor 700 may be constituted by one or moreconventional processors. Processor 700 operates to executeprocessor-executable steps, contained in program instructions describedbelow, so as to control the payment card issuer server computer 112 toprovide desired functionality.

Communication device 701 may be used to facilitate communication with,for example, other devices (such as the payment system 110 or, as willbe seen, the payment-enabled mobile telephone 102 via an over-the-aircommunication channel). For example, communication device 701 maycomprise numerous communication ports (not separately shown), to allowthe payment card issuer server computer 112 to communicatesimultaneously with a number of other computers and other devices,including communications as required to simultaneously handle numeroustransaction authorization requests from the payment system 110.

Input device 706 may comprise one or more of any type of peripheraldevice typically used to input data into a computer. For example, theinput device 706 may include a keyboard and a mouse. Output device 708may comprise, for example, a display and/or a printer.

Storage device 704 may comprise any appropriate information storagedevice, including combinations of magnetic storage devices (e.g.,magnetic tape and hard disk drives), optical storage devices such as CDsand/or DVDs, and/or semiconductor memory devices such as Random AccessMemory (RAM) devices and Read Only Memory (ROM) devices, as well asso-called flash memory. Any one or more of such information storagedevices may be considered to be a computer-readable storage medium or acomputer usable medium or a memory.

Storage device 704 stores one or more programs for controlling processor700. The programs comprise program instructions (which may be referredto as computer readable program code means) that containprocessor-executable process steps of the payment card issuer servercomputer 112, executed by the processor 700 to cause the payment cardissuer server computer 112 to function as described herein.

The programs may include one or more conventional operating systems (notshown) that control the processor 700 so as to manage and coordinateactivities and sharing of resources in the payment card issuer servercomputer 112, and to serve as a host for application programs (describedbelow) that run on the payment card issuer server computer 112.

The programs stored in the storage device 704 may also include atransaction handling application program 710 that controls the processor700 to enable the payment card issuer server computer 112 to handlevarious transactions, including authorization requests for payment cardsystem purchase transactions.

Another program that may be stored in the storage device 704 is anapplication program 712 that selects configuration options for paymentapplication programs loaded or to be loaded in the payment-enabledmobile devices that operate with the system 110 (FIG. 1).

The programs stored in the storage device 704 may also include anapplication 714 that programs the payment card issuer server computer112 to manage personalization of mobile telephones (and possibly otherpayment devices as well) authorized by the issuer to access payment cardaccounts issued by the issuer. The payment card issuer server computer112 may perform conventional personalization functions in addition tothe operations described herein. (Or, in other embodiments, thepersonalization and payment application configuration functions may behandled by another computer—operated by or on behalf of the issuer—thatis separate from, but possibly cooperative with, the payment card issuerserver computer 112.)

The storage device 704 may also store, and the payment card issuerserver computer 112 may also execute, other programs, which are notshown. For example, such programs may include a billing application,which handles generation of bills to users and which tracks whetherpayments are received as required. The other programs may also include,e.g., device drivers, etc.

The storage device 704 may also store one or more databases 716 requiredfor operation of the payment card issuer server computer 112, includingdata regarding users' payment card account balances and transactions.

FIG. 8 schematically illustrates personalization of payment-enabledmobile telephone 102 for payment enablement purposes. As before, block112 represents a server computer operated by or on behalf of an issuer(financial institution) of payment card accounts. The payment cardissuer server computer 112 is the source of information that is loadedinto the payment-enabled mobile telephone 102 for the purpose of“personalizing” the payment-enabled mobile telephone 102. Arrow 802schematically illustrates a communication channel by which thepersonalization information is transmitted from the payment card issuerserver computer 112 to the payment-enabled mobile telephone 102.

As is familiar to those who are skilled in the art, “personalization”refers to the process by which user- and/or account-specific informationis loaded into and/or otherwise applied to a payment device (e.g., acontactless payment card or payment-enabled mobile telephone or magstripe payment card). In connection with traditional mag stripe paymentcards, the personalization process includes magnetically storing thecardholder's name and the payment card account number and otherinformation on the mag stripe, and also printing/embossing thecardholder's name and account number, etc., on the plastic body of thecard. For a conventional contactless payment card, personalization mayinclude similar printing or embossing, plus storage of cardholder nameand account number and other information by RF wireless communicationinto an integrated circuit (IC) embedded in the body of the contactlesspayment card. Personalization of a payment-enabled mobile telephone alsoentails storage of information in an IC contained within the phone.According to one conventional proposal, the information is communicatedto the mobile telephone over the air (OTA) via the mobile communicationnetwork by a data communication session between the mobile telephone andthe issuer's server. It has also been proposed that personalization ofthe mobile telephone may include the downloading to the mobile telephoneof the payment application program.

The above-mentioned OTA communication channel may be one embodiment ofthe personalization channel 802 shown in FIG. 8. According to anotherproposal (and as disclosed in co-pending and commonly assigned U.S.patent application Ser. No. 11/870,144—published as U.S. Publication No.2009/0100511), the personalization information for a particular user'smobile telephone is loaded into a contactless IC card from the issuer'sserver computer and then the contactless IC card is sent to the user.The user/cardholder then brings the contactless IC card into proximitywith the mobile telephone to permit loading of the personalizationinformation via RF communication from the IC card to the mobiletelephone. This technique is another possible embodiment of thepersonalization channel 802 shown in FIG. 8. The contactless IC carddescribed in this paragraph, into which programs and/or data are loadedto in turn be loaded into a mobile telephone or other device, mayhereinafter be referred to as a “personalization card” or “perso card”,for short.

In other embodiments, the personalization channel 802 may be constitutedby any other personalization technique previously or hereafter proposed.

In some embodiments, the personalization (or “pre-personalization”) of apayment-enabled mobile telephone by the issuer server 112 may includeloading the payment application program into the payment-enabled mobiletelephone and/or configuration of the payment application program toselect among risk management practices described herein.

FIGS. 9A and 9B together form a flow chart that illustrates a processthat may be performed in the system 100 according to aspects of thepresent invention. In particular, FIGS. 9A and 9B illustrate operationof the payment-enabled mobile telephone 102 and functionality providedby the payment application program 502 (FIG. 5) in the payment-enabledmobile telephone 102 in cooperation with the user interface program 504.To briefly summarize aspects of this process, the payment applicationprogram may apply various different cardholder verification ortransaction acknowledgement requirements depending on one or moreattributes of the current transaction. In the particular exampledepicted in FIGS. 9A and 9B, there are three categories oftransaction—defined by transaction amount—for which differentrequirements (or the absence of any required action) are assigned. Thecardholder verification requirement may protect against misuse of thepayment capabilities of the payment-enabled mobile telephone 102. Thetransaction acknowledgment requirement may protect against unauthorizedreading of the user's account information from the payment-enabledmobile telephone 102, and may help to assure that the transaction asdefined by the merchant complies with what the user believes thetransaction to be.

The process of FIGS. 9A and 9B may idle in an inactive state, until thepayment-enabled mobile telephone 102 detects that it has been tapped onthe proximity reader component 104 of a POS terminal. Then, at decisionblock 902, the payment application program determines whether this isthe first time the payment-enabled mobile telephone 102 has been tappedon the proximity reader component 104 (resulting in an exchange ofwireless communication) in connection with the current transaction. Thisdetermination may be made for example, by referring to a flag thatindicates whether the payment application program is already storingtransaction context data (e.g., a transaction amount and currencyidentifier). If transaction context data is already present, then theprocess advances from decision block 902 to block 904. Block 904represents what will be referred to herein as “second tap processing”,as will be described below in connection with FIG. 12.

If, on the other hand, it is determined at decision block 902 that theexchange of communications with the proximity reader component 104 isfor a “first tap”, then the process advances from decision block 902 toblock 906. At block 906, the payment application program stores thetransaction context data for the current transaction, as received at the“first tap” from the POS terminal 106. As noted above, in someembodiments, the transaction context data may include or consist of thetransaction amount and an indication (e.g., a code) that identifies thecurrency in which the transaction is being conducted.

The payment application program then determines, based on thetransaction amount, the transaction amount category into which thetransaction falls. Thus, at decision block 908, the payment applicationprogram determines whether the transaction is a “low dollar (monetaryamount)” transaction, say not more than ten dollars. If so, then thepayment application program allows the transaction to be consummated atthe first tap. That is, it is assumed that the processing for steps 902,906, 908, 910 occurs while the payment-enabled mobile telephone 102remains in proximity to the proximity reader component 104 during thefirst tap, and that the resulting exchange of communications involvesthe payment-enabled mobile telephone 102 communicating the user'spayment card account number to the proximity reader component 104.Consummation of the transaction is indicated at block 910.

Decision block 912 represents a determination by the payment applicationprogram as to whether the transaction is for a “medium dollar” amount,say more than ten dollars but not more than 20 dollars. If so, theapplicable risk management requirement may call for the user to“acknowledge” (ACK; i.e., enter input to accept) the transaction. Insome embodiments, ACK/acceptance may be pre-entered prior to the firsttap for a transaction. Accordingly, when the transaction is for a“medium dollar” amount, the process may advance from decision block 912to decision block 914. At decision block 914, the payment applicationprogram determines whether in fact the user has pre-entered “ACK”. Ifso, the process consummates the transaction on the first tap, such thatblock 910 follows decision block 914 in this case. Otherwise, theprocess advances from decision block 914 to block 916.

At block 916, the payment-enabled mobile telephone 102 displays a promptto the user to indicate that the user needs to accept the transaction.FIG. 10 shows an example screen display that may be displayed to theuser in this case (it is assumed that the payment-enabled mobiletelephone 102 includes a touch screen on which this screen display ispresented). Referring to FIG. 10, the name of the retailer (entity thatoperates the POS terminal 106) is indicated at 1002. The amount of thetransaction is displayed at 1004. (The “$” sign identifies thecurrency.)

At 1006, the payment-enabled mobile telephone 102 displays the prompt tothe user to accept/ACK the transaction. The user is to do so byactuating (touching) the virtual “accept” button which appears at 1008.(Alternatively, e.g., in cases where the payment-enabled mobiletelephone 102 does not have a touch screen, the user may have the optionof signaling ACK by actuating a soft key or in another conventionalmanner.) If the user wishes to cancel the transaction, he/she may do soby touching the “cancel” button 1010, which is also provided as part ofthe screen display.

Referring again to FIG. 9A, at 918 the payment application determineswhether the user has ACK'd. If so, then block 920 follows decision block918. At block 920 the payment application program sets a flag toindicate that a required ACK/accept indication has been received fromthe user. If the ACK indication is not received, then the processbranches at 922 from decision block 918, such that the process by-passesblock 920 (and so does not set the ACK status flag). At decision block923, it is determined whether the user has actuated the “cancel” button(FIG. 10). If so, the transaction is aborted and the process loops back(via branch 925) to decision block 902. Otherwise, the process awaits asecond tap (block 924). (In some embodiments, there may also be a timeout function, such that the process aborts and loops back to 902 if thesecond tap or the ACK indication do not occur within a predeterminedperiod of time.) (To partially preview the process of FIG. 12, if ACKwas required but the ACK status flag was not set, any second tap willresult in the payment-enabled mobile telephone 102 declining thetransaction. The process may then be repeated with a third (or fourth,etc.) tap until the ACK is received or the transaction is canceled bythe user.)

Referring again to decision blocks 908 and 912 in FIG. 9A, if thepayment application program determines that the transaction is neither alow nor a medium dollar amount application, then the payment applicationprogram determines that the transaction is a high dollar amounttransaction, as indicated at block 926 (following the “no” branch 928from decision block 912). Decision block 930 then follows block 926.

At decision block 930, the payment application program determineswhether the user had pre-entered his/her PIN (and that the PIN had beenverified by the payment application program). If so, then the processconsummates the transaction on the first tap, such that block 910follows decision block 930 (via branch 932 from block 930). Otherwise,the process advances from decision block 930 to block 934.

At block 934, the payment-enabled mobile telephone 102 displays a promptto the user to indicate that the user needs to enter his/her PIN. FIG.11 shows an example screen display that may be displayed to the user inthis case (as with FIG. 10, it is again assumed that the screen displayis shown on a touch screen component of the payment-enabled mobiletelephone 102).

Referring to FIG. 11, the retailer is identified at 1102 and the amountof the transaction (with currency indication) is displayed at 1104. Theactual “enter PIN” prompt appears at 1106 and a field 1108 is alsoprovided to acknowledge entry of each digit of the PIN. A virtualnumeric keypad is displayed at 1110 to permit the user to enter thedigits of the PIN. (In alternative embodiments, for example, in theabsence of a touch screen/virtual keypad, the user may operate an actualnumeric keypad on the phone in order to enter the digits of the PIN.) A“cancel” button is provided at 1112.

Referring again to FIGS. 9A and 9B, it will be noted that decision block936 in FIG. 9B follows block 934 shown in FIG. 9A. At decision block936, the payment application program determines whether the PIN has beenentered, and if so, decision block 938 (FIG. 9B) follows decision block936. At decision block 938, the payment application program determineswhether the PIN, as entered by the user, is valid. For example, thepayment application program may compare the PIN as entered with aversion of the PIN that has been securely stored (e.g., in atamper-resistant memory) in the payment-enabled mobile telephone 102. Ifthe payment application program determines that the PIN as entered isvalid, then block 940 follows decision block 938. At block 940, thepayment application program sets a flag to indicate that the user hasentered the PIN and that the PIN as entered has been verified. But ifthe user does not enter the PIN or the PIN is incorrect, then theprocess of FIGS. 9A and 9B by-passes block 940 so that the PINverification status flag is not set. In this example as illustrated inthe drawings, invalid entry of the PIN causes the process to loop backto block 934 (FIG. 9A), via branch 941 from decision block 938, so thatthe user is prompted to try again to enter the PIN (it will berecognized that a “try again” variation on the screen display of FIG. 11may be employed). In some embodiments, the number of retries that ispermitted may be limited by the payment application program. Also in theexample shown in FIGS. 9A and 9B, the process branches at 943 fromdecision block 936 to decision block 942 (FIG. 9B) if the PIN has notbeen entered, by-passing block 940. (In other cases, decision block 942follows blocks 938 and 940.) At decision block 942, it is determinedwhether the user has actuated the cancel button. If so, the processloops back to decision block 902 (FIG. 9A) via branch 944 from decisionblock 942. Otherwise, at block 946, the process awaits a second tap ofthe payment-enabled mobile telephone 102 on the proximity readercomponent. Again, a time-out function may be in effect to abort thetransaction in the absence of any action from the user. As will be seenfrom the ensuing discussion of FIG. 12, if PIN entry was required anddid not validly occur, then the second tap results in the transactionbeing declined. The process may then be repeated with a third (orfourth, etc.) tap until the PIN is entered or the transaction iscanceled by the user.

FIG. 12 is a flow chart that illustrates a process for handling a“second tap”. The process of FIG. 12 begins with block 1202, at whichthe second tap occurs. Once this takes place, the process advances fromblock 1202 to block 1204. At block 1204, the payment application programagain receives the transaction context data (e.g., dollar amount andcurrency) from the POS terminal 106. In normal cases, the context datareceived at 1204 is the same as the data stored at the first tap (block906, FIG. 9A)—that is, the second tap is for the same transaction as thefirst tap. However, to prevent or deter certain kinds of attacks on thepayment system, it is advisable that the payment application program beconfigured to compare the second tap transaction context with the firsttap transaction context. This step is indicated at 1206 in FIG. 12. Thepayment application program then determines at decision block 1208whether there is a conflict between the first and second tap transactioncontexts. If so, then the payment application program declines thetransaction, as indicated at block 1210. Normally, however, there willbe no conflict, and in those cases the process advances from decisionblock 1208 to decision block 1212.

(The transaction context data stored in the payment-enabled mobiletelephone 102 between taps, in addition to currency and transactionamount, may include an indication that the payment application programis awaiting a second tap, an indication as to whether a PIN or ACK wasentered, and whether a “L&S” counter or accumulator—described below inconjunction with FIG. 19—has exceeded its limit.)

At decision block 1212, the payment application program determineswhether PIN entry was required in connection with the first tap (asuitable flag indicating that PIN entry/CVM was required may have beenset in connection with the first tap). If PIN entry was required, thenthe process advances from decision block 1212 to decision block 1214. Atdecision block 1214, the payment application program determines whetherthe PIN verification status flag is set. If so, the transaction isconsummated as indicated at block 1216 (i.e., the payment-enabled mobiletelephone 102/payment application program transmits to the POS terminal106 the commitment of the user's payment card account number to thetransaction and possibly certain security procedures are performed). Ifthe PIN verification status flag is not set, then the paymentapplication program declines the transaction (block 1217) and theprocess may then loop back to block 1202 (awaiting a second tap).

Referring again to decision block 1212, if the payment applicationprogram determines that PIN entry was not required in response to thefirst tap, then the process advances from decision block 1212 todecision block 1218. At decision block 1218, the payment applicationprogram determines whether user acceptance/acknowledgement (ACK) wasrequired in connection with the first tap (again a suitable flagindicating the ACK requirement may have been set in connection with thefirst tap). If so, then the process advances from decision block 1218 todecision block 1220. At decision block 1220, the payment applicationprogram determines whether the ACK status flag is set. If so, block 1216(transaction consummation) follows decision block 1220. Otherwise, block1217 (transaction declined) follows decision block 1220.

In the example embodiments illustrated with FIGS. 9-12, one class oftransactions is handled with one tap of the payment-enabled mobiletelephone 102 on the proximity reader component of the POS terminal 106;a second class of transactions requires two taps, with an ACK by theuser between the two taps; and a third class of transactions requirestwo taps, with PIN entry and verification between the two taps. In thisexample, the transaction classes were defined in terms of transactionamounts, but other transaction class definitions are possible. Forexample, all and only gasoline service station at-the-pump transactionsmay be one tap, all other domestic currency transactions may be two-tapwith ACK required, and all foreign currency transactions (other thanat-the-pump) may be two-tap with PIN required. Those who are skilled inthe art will recognize that many other definitions of three transactioncategories may be implemented. To provide one other example, in someembodiments, “zero” monetary amount transactions (e.g., transit entrytransactions) may be “one tap” transactions, non-zero transactions belowa monetary amount limit may be two-tap-with-ACK transactions, andtransactions at or above the monetary amount limit may betwo-tap-with-PIN transactions.

FIGS. 13 and 14 are each flow charts that illustrate additionalprocesses that may be implemented in the payment-enabled mobiletelephone 102 in accordance with aspects of the invention via thepayment application program. One advantage provided with the processesof FIGS. 13 and 14 is that a payment card account issuer may bepermitted to specify classes of transactions for which PIN pre-entry isor is not allowed. For example, an issuer may allow PIN pre-entry onlyfor transit system transactions, and may require two taps with PIN entryafter the first tap and before the second for all other transactions.

Referring then to FIG. 13, at decision block 1302, the process of FIG.13 idles until the user invokes a PIN pre-entry function on thepayment-enabled mobile telephone 102. (For example, the user may selectthis function by interacting with a menu provided on the displaycomponent of the payment-enabled mobile telephone 102.) Upon the userselecting the PIN pre-entry function, the process advances from decisionblock 1302 to block 1304. At block 1304, the payment-enabled mobiletelephone 102 may prompt the user to pre-enter his/her PIN. For example,this could be done with a screen display that resembles FIG. 11, exceptwith a legend/heading such as “PIN PRE-ENTRY” replacing elements 1102and 1104 in the screen display of FIG. 11.

Decision block 1306 follows block 1304 in FIG. 13. At decision block1306, the payment-enabled mobile telephone 102 (e.g., the user interfaceprogram and/or the payment application program) determines whether thePIN has been entered. If so, decision block 1308 follows decision block1306. At decision block 1308, the payment application program determineswhether the PIN, as entered by the user, is valid. This process step mayresemble step 938 in FIG. 9B, as described above.

If the PIN is found to be valid, then block 1310 follows decision block1308. At block 1310, the payment application program sets the PINverification status flag to indicate that the user has entered the PINand the PIN as entered was verified.

Referring again to decision blocks 1306 or 1308, if the PIN is notentered or is invalid, the process may loop back to block 1304. (Thisloop may be subject to a time-out function.)

Typically, the process of FIG. 13 is likely to be performed at theuser's instigation at a time just before the user taps thepayment-enabled mobile telephone 102 on a proximity reader component toinitiate a payment/purchase transaction. FIG. 14 then picks up thesequence of events in response to the tapping of the payment-enabledmobile telephone 102 on the proximity reader component.

The process of FIG. 14 idles, as indicated by decision block 1402, untilthe “tap” occurs. When the tap takes place, the process of FIG. 14advances from decision block 1402 to decision block 1404. At decisionblock 1404, the payment application program determines whether thetransaction (as identified by the information received from theproximity reader component) is qualified for handling via pre-entry ofthe user's PIN. If so, the process of FIG. 14 advances from decisionblock 1404 to decision block 1406.

At decision block 1406, the payment application program determineswhether the PIN verification flag is in its “set” state (as will be thecase if step 1310 in FIG. 13 has been executed.) If the PIN verificationflag has been set, the payment-enabled mobile telephone 102 consummatesthe transaction (block 1408) as part of the exchange of communicationswith the proximity reader component in connection with the “tap”detected at 1402. If the PIN verification flag has not been set and ifthe PIN is required for the transaction (for example, if it is a highvalue transaction), then the payment-enabled mobile telephone 102declines the transaction (block 1410). Alternatively, in a branch notshown in the drawing, the process may segue to a sequence of steps likethose led by block 934 in FIG. 9A.

Considering decision block 1404 again, if at that point in the processthe payment application program determines that the transaction is notone that qualifies for PIN pre-entry, then the process of FIG. 14advances from decision block 1404 via branch 1412 to block 1414. Atblock 1414, the payment application program clears the PIN verificationstatus flag. (It should be understood that the PIN verification flag mayalready be in a non-set—i.e., cleared—state at the time the processarrives at block 1414, in which case the action at block 1414 does notchange the state of the PIN verification flag.)

The process of FIG. 14 advances from block 1414 to block 1416. At block1416, the payment-enabled mobile telephone 102 may prompt the user toenter his/her PIN if the PIN is required for the transaction (forexample, if it is a high value transaction). Again, a screen displaylike that shown in FIG. 11 may accordingly be presented to the user bythe payment-enabled mobile telephone 102.

Decision block 1418 follows block 1416 in FIG. 14. At decision block1418, the payment application program determines whether the PIN hasbeen entered. If so, decision block 1420 follows decision block 1418. Atdecision block 1420, the payment application program determines whetherthe PIN, as entered by the user, is valid. (Again this may be done asdescribed with reference to block 938 in FIG. 9B.)

If the payment application program determines at decision block 1420that the entered PIN is valid, then block 1422 follows decision block1420. At block 1422, the payment application program sets the PINverification flag. Next, at decision block 1424, the payment applicationprogram awaits the “second tap” of the payment-enabled mobile telephone102 on the proximity reader components. Once this occurs, the process ofFIG. 14 advances from decision block 1424 to decision block 1406, etc.,as described above.

Referring again to decision blocks 1418 and 1420, if no PIN is entered,or the PIN as entered is incorrect, the process may loop through blocks1416, 1418 and/or 1420. This loop may be subject to a time-out functionand/or a limit on the number of re-tries for entering the PIN.

Processes similar to those of FIGS. 13 and 14 may be implemented forpre-entry of ACK, and the issuer and/or the user may specify a class orclasses of transaction for which ACK pre-entry is permitted or notpermitted.

FIG. 15 illustrates still another process that may be implemented in thepayment-enabled mobile telephone 102 in accordance with aspects of thepresent invention. In some embodiments, the process of FIG. 15 may beinterposed between the processes of FIG. 13 and FIG. 14 and/or betweensteps 1422 and 1424 in FIG. 14.

FIG. 15 is relevant to embodiments in which the PIN verification flag isallowed to be in a set condition only for a limited period of time afterthe payment application program verifies a PIN as entered by the user.This limited period of time may, for example, be enforced by a (softwarebased) count-down timer function that begins operation when the PINverification flag is initially set and that causes the PIN verificationflag to be cleared when the count-down timer reaches zero. An advantageprovided by the process of FIG. 15 is to improve user friendliness ofthe payment-enabled mobile telephone 102 by informing the user how muchtime he/she has left before the PIN verification status expires.

Referring then to FIG. 15, the process begins with block 1502, uponsetting of the PIN verification status flag (as in, e.g., block 1422 inFIG. 14, block 1310 in FIG. 13, or block 940 in FIG. 9B). Block 1504then follows block 1502. At block 1504, the payment-enabled mobiletelephone 102 starts a count-down timer function with respect to the PINverification flag. For example, the timer function may start at “6minutes” (6:00) and may count down from there toward zero. The currentvalue of the count-down timer function indicates a future point in timeat which the PIN-verified status of the payment application program willexpire.

Block 1506 follows block 1504. At block 1506, the payment-enabled mobiletelephone 102 may provide to the user a screen display such as thatshown in FIG. 16. It will be noted that the screen display includes aprompt at 1602 to the user to tap the payment-enabled mobile telephone102 to complete (or initiate) the current transaction. The screendisplay of FIG. 16 also includes a field 1604 which displays the currentvalue of the count-down timer function. The display may be dynamic inthat each time (i.e., each second) the current value of the count-downtimer changes, the value displayed in the field 1604 is updated toreflect the change in the current value of the count-down timer.

The process of FIG. 15 includes a loop of decision blocks 1508, 1510,1512.

If the user actuates a “more time” button 1606 shown in FIG. 16, thenthe process of FIG. 15 branches out of the loop from decision block 1508to block 1514. At block 1514, the payment-enabled mobile telephone 102re-starts the count-down timer function. This may include increasing thecurrent value of the timer function to its original value, or simplyadding some time to the current value. The process of FIG. 15 then loopsback to block 1506 from block 1514.

If the user taps the payment-enabled mobile telephone 102 on theproximity reader component, then the process of FIG. 15 branches out ofthe loop from decision block 1510 to block 1516, at which thetransaction is processed.

If the timer function reaches zero before the user requests more time ortaps the phone on the proximity reader component, then the processbranches out of the loop from decision block 1512 to block 1518. Atblock 1518, the payment application program clears the PIN verificationstatus flag. In addition, the payment-enabled mobile telephone 102 maypresent a screen display like FIG. 17 to the user. In this screendisplay, the user is informed that the timer has expired and that he/sheneeds to re-enter his/her PIN.

A process like FIG. 15, with accompanying count-down function, may alsobe triggered by the user's entry or pre-entry of an ‘ACK’ signal.

FIG. 18 is a flow chart that illustrates still another process that maybe implemented for risk management purposes in the payment applicationprogram according to aspects of the present invention. In this process,cardholder verification may be required for transactions conducted in acurrency other than the user's home currency, but may not be requiredwhen the transaction is in the user's home currency.

At decision block 1802 in FIG. 18, the process idles until thepayment-enabled mobile telephone 102 is tapped on a proximity readercomponent. Once this occurs, the process advances from decision block1802 to decision block 1804. At decision block 1804, the paymentapplication program determines whether a currency identifier included inthe transaction information (from the POS terminal 106, in the exchangeof communications during the “tap”) indicates that the currenttransaction is in the user's home currency (i.e., in the currency inwhich the user's payment card account is denominated). If so, block 1806follows decision block 1804. At block 1806, the payment-enabled mobiletelephone 102 consummates the transaction as part of the communicationswith the POS terminal 106 during the tap detected at 1802, and withoutrequiring cardholder verification.

However, if at decision block 1804 the payment application programdetermines that the currency for the current transaction is not theuser's home currency, then cardholder verification ensues. That is,block 1808 follows decision block 1806. At block 1808 the user isprompted to enter his/her PIN. For example, a screen display similar toFIG. 11 may be used, except that the screen display may include aspecific notification to the user as to the currency being used for thetransaction (e.g., “This transaction is in British pounds.”).

Decision block 1810 follows block 1808. At decision block 1810, it isdetermined whether the PIN has been entered. If so, decision block 1812follows decision block 1810. At decision block 1812, the paymentapplication program determines whether the PIN, as entered by the user,is valid. This may occur, for example, as described in connection withblock 938 in FIG. 9B.

If at decision block 1812 the payment application program determinesthat the PIN is valid, then block 1814 follows decision block 1812. Atblock 1814, the payment application program sets the PIN verificationstatus flag. Next, at decision block 1816, the process awaits the“second tap” of the payment-enabled mobile telephone 102 on theproximity reader. Upon the second tap taking place, the transaction issuccessfully processed (block 1822), assuming that the PIN verificationstatus flag has been set. It will be noted that according to other pathsin the flow chart of FIG. 18, block 1814 may be by-passed because thePIN is not entered or is found to be invalid. In these cases, the PINverification status is not set and the subsequent processing at thesecond tap results in the transaction being declined.

In some embodiments, the process of FIG. 18 may be modified such that,instead of requiring PIN entry and verification for non-home-currencytransactions, the process requires an ACK from the user beforeconsummating the transaction at the second tap.

Typically, the currency for the transaction is indicated by a currencycode, and the decision at block 1804 may be based on whether thecurrency code received from the POS terminal matches the currency codefor the user's home currency. In some transactions (e.g., for transitaccess) the currency code indicator may be a null indicator. In someembodiments, the null indicator may result in PIN verification or ACKbeing required; in other embodiments, the null indicator will not causesuch requirements.

FIG. 19 is another flow chart that illustrates a process that may beperformed in the payment-enabled mobile telephone 102 in accordance withaspects of the present invention. As some background to FIG. 19, in someembodiments of the payment-enabled mobile telephone 102, thepayment-enabled mobile telephone 102 may store two counters and twoaccumulators. For example, the counters and accumulators may beimplemented in the NVM 428 shown in FIG. 4. Each counter may count thenumber of transactions for which the payment-enabled mobile telephone102 has been used since the respective counter was reset. Eachaccumulator may store the cumulative value of all transactions for whichthe payment-enabled mobile telephone 102 was used since the respectiveaccumulator was reset. One of the counters may be associated with one ofthe accumulators and both may be reset at the same time. The othercounter may be associated with the other accumulator and again the othercounter and accumulator may both be reset at the same time, although notnecessarily at the same time as the first counter and accumulator.

The first counter/accumulator combination may be used for one purposeand the second counter/accumulator combination may be used for adifferent purpose. For example, the first counter/accumulatorcombination may be used for financial risk management purposesprescribed by the issuer—e.g., to track the usage of the payment aspectsof the payment-enabled mobile telephone 102 relative to prepaid fundsstored in the payment-enabled mobile telephone 102, and to enforce atop-up requirement when the prepaid funds are exhausted. The secondcounter/accumulator combination may be used for risk management relativeto the possibility that the payment-enabled mobile telephone 102 may belost or stolen. In this respect (and as will be seen from the followingdiscussion of FIG. 19), the second counter/accumulator combination maybe used to enforce a cardholder verification requirement after a certainnumber of, and/or a certain cumulative value of, transactions since thelast time the second counter/accumulator combination was reset.

Turning now to FIG. 19, at decision block 1902 the process idles untilthe payment-enabled mobile telephone 102 is tapped on the proximityreader component. Once this occurs, block 1904 follows decision block1902. At block 1904, the payment application program checks the currentvalue of either or both of the first counter and the first accumulatorto determine whether the current value is in excess of a limitprescribed for financial risk management purposes by the issuer of theuser's payment card account. (Alternatively, the checking of the firstcounter/accumulator value may be for some other purpose.)

Following block 1904 is decision block 1906, at which the paymentapplication program determines whether the current value of the firstcounter and/or first accumulator is acceptable for continuing with thetransaction. If not, the payment-enabled mobile telephone 102 declinesthe transaction, as indicated at 1908. (As part of 1908, thepayment-enabled mobile telephone 102 may display to the user a suitableerror message and/or prompt, such as “Please top-up your pre-paidaccount before this transaction”.)

If at decision block 1906 the first counter and/or first accumulatorvalue is not found to be problematic, then the process of FIG. 19advances to block 1910. At block 1910, the payment application programchecks the current value of either or both of the second counter and thesecond accumulator to determine whether either or both have exceeded a“lost or stolen” (L&S) limit. (Alternatively, the secondcounter/accumulator combination may be used for another purpose besidesL&S risk management.)

At decision block 1912, the payment application program determineswhether either or both of the L&S counter/accumulator current value isacceptable. If so, block 1914 follows. At block 1914, thepayment-enabled mobile telephone 102 consummates the currenttransaction, which may take place during the same exchange ofcommunications that was initiated by the “tap” detected at 1902.

However, if the payment application program determines at decision block1912 that the L&S counter and/or accumulator has exceeded the L&S riskmanagement limit, then the process advances from decision block 1912 toblock 1916. At block 1916, the payment-enabled mobile telephone 102prompts the user to enter his/her PIN. For example, the payment-enabledmobile telephone 102 may present a screen display like that shown inFIG. 11.

Decision block 1918 follows block 1916. At decision block 1918, thepayment application program determines whether the PIN has been entered.If so, the process of FIG. 19 advances from decision block 1918 todecision block 1920. At decision block 1920, the payment applicationprogram determines whether the PIN, as entered by the user, is valid.This may be done, for example, in the manner described above inconnection with block 938 in FIG. 9B.

If the payment application program determines that the PIN as entered isvalid, then block 1922 follows decision block 1920. At block 1922, thepayment application program resets the L&S counter and accumulator. Theprocess of FIG. 19 may then loop back to decision block 1902, such thatthe user may “second tap” the payment-enabled mobile telephone 102 onthe proximity reader component. The second tap will result in theprocess following the path through blocks 1904, 1906, 1910 and 1912;arriving at consummation of the transaction (block 1914).

Otherwise, if the PIN is not entered, or is not entered correctly, theprocess of FIG. 19 may branch or loop back so as to by-pass block 1922.A suitable time-out function and/or PIN retry limit may be present toprevent indefinite looping of the process of FIG. 19.

In some embodiments, the L&S counter/accumulator may be reset each timethe user enters a valid PIN, whether the user was prompted to do so forpurposes of L&S risk management or for another reason (e.g. for a highvalue transaction).

The following discussion will provide background to FIGS. 20A, 20B and20C and, among other subjects, is concerned with issuer and/or userconfiguration of the payment application program, and temporary versuspermanent updating of counters and/or accumulators associated with thepayment application program.

When a card (or other payment device such as a payment-enabled mobiletelephone) is presented to a terminal (e.g., in accordance with the EMVor PayPass processes), the terminal first performs some checks and thenwill ask the card to provide a cryptogram. There are three types ofcryptograms (and so three types of requests from the terminal): (1) AAC(“application authentication cryptogram”)—for a declined transaction;(2) ARQC (“authorization request cryptogram”)—for an online transaction(This cryptogram is sent online to the issuer for authorization. Theissuer will then decide to approve or decline the transaction and informthe terminal in the authorization response about that decision.); and(3) TC (“transaction certificate”)—for an approval from the card ordevice. If a TC is requested by the terminal at the beginning of thetransaction, before going online to the issuer, then the intention ofthe terminal is to have the transaction offline approved, i.e. approvedwithout going online to the issuer.

The possibilities for the card are consequently as follows: (1) Theterminal asks for an AAC (In this case, the card can only decline, i.e.provide the AAC.); (2) the terminal asks for an ARQC (The card can thenprovide the ARQC for online authorization, or the card can decline thetransaction and provide an AAC); or (3) the terminal asks for a TC (Thecard can then provide the TC—the transaction is then offline approved orthe card can then provide an ARQC for online authorization or the cardcan decline the transaction and provide an AAC).

In these situations, the card/payment device makes an analysis to decideabout how the transaction will be performed. This analysis may be basedon a number of different factors, but for present purposes only theanalysis as it relates to the state of counters and accumulators oftransactions will be considered.

Consider the Following Examples:

An “offline-only” card never goes online. When the terminal is askingfor an ARQC from such a card, it will always receive an AAC.

An offline/online card may decide, when the terminal asks for a TC, togive the TC (so offline approve) if an accumulator is below a certainlimit or return an ARQC if the accumulator is above the limit.Typically, this accumulator could cumulate all successive offlinetransactions; and the issuer may allow transactions to be offline untila threshold (limit) is reached. When the limit is reached, the issuerwants to see the card (i.e., an online transaction is required; thisprotects against over spending).

At personalization, the issuer may configure the card/payment device(i.e., may configure the payment application program in the paymentdevice) so that the device will take one decision or another dependingon the circumstances. This may work as follows:

For each accumulator and counter, two limits may be assigned atpersonalization: the lower limit and the upper limit.

For the analysis in response to the interaction with the terminal, thecard/payment device compares the accumulators and counters to theirrespective limits. The payment application program sets a bit ininternal data (the CVR—item 526, FIG. 5A) when a limit is reached. Forinstance, if there is only one counter and one accumulator in the card:there would be four relevant bits in the CVR: (1) Counter lower limitexceeded, (2) counter upper limit exceeded, (3) accumulator lower limitexceeded, and (4) accumulator upper limit exceeded. In a case where thecounter has reached the counter lower limit and the accumulator hasreached the accumulator upper limit, the card would set the two bits“Counter lower limit exceeded” and “Accumulator upper limit exceeded” inthe CVR 526.

Now the issuer may configure the payment application program todetermine which action is to be taken in various circumstances bypersonalizing other data called CIACs or CIAC bits (“card issuer actioncode”—also referred to as the control mask 530 in FIG. 5A). The CIACbits would also be four bits in the example, defining the action to takewhenever a corresponding bit in the CVR is set. The card risk managementportion of the payment application program makes use of 4 different CIACbits (numerals 1, 2, 3, 4 located in circles associated with decisionblocks in FIGS. 20A and 20B) with each CIAC having four bitscorresponding to the four bits in the CVR, i.e. there are four differentcomparisons between a CIAC and the CVR. For each of these comparisons,the corresponding CIAC defines the decision based on the state of thecounter or accumulator.

Referring now to FIG. 20A, it is assumed that the terminal is requestingan ARQC (block 2002), the card will use CIAC 1 (circle 2004/decisionblock 2006) and the decision will be either to decline (AAC—block 2008)or to go online (ARQC—block 2010). If for example the CVR bit “Counterlower limit exceeded” is set and the corresponding bit in the CIAC1 isset, the card would decline.

If the terminal is requesting a TC (FIG. 20B, block 2050) and theterminal is offline only, the card will use CIAC 2 (circle 2052/decisionblock 2054 and the decision will be either to decline (AAC—block 2056)or to approve offline (TC—block 2058). If for example the CVR bit“Counter upper limit exceeded” is set and the corresponding bit in theCIAC 2 is set, the card would decline.

There are also other settings, personalized in the card/paymentdevice/payment application program, used to determine what decisions thedevice will make.

There may be a setting at application level for the payment applicationprogram to indicate whether the card/payment device is or is not offlineonly. This is represented by a capital “A” in the drawings (e.g., circle2060, FIG. 20B) in the ensuing discussion.

There may be settings at the resource level (so settings can bepersonalized differently for each accumulator and counter). These arerepresented by lower case letters a, b, c, d, x, y (in circlesassociated with decision blocks) in the drawings.

The lower case letters a, b, c, d define, for each accumulator andcounter, if the application should count/accumulate the currenttransaction temporarily before checking the following CIAC. For example,setting “b” (circle 2062, FIG. 20B) is used to define if, when settingthe CVR bits before the comparison with CIAC2, the current transactionshould be counted or accumulated. Further, setting “a” (circle 2012,FIG. 20A) is used to define if, when setting the CVR bits before thecomparison with CIAC1, the current transaction should be counted oraccumulated. This inclusion of the current transaction or not is donetemporarily, i.e. only for the comparison with the following CIAC.

Settings “x” and “y”, in turn, define, for each accumulator or counterindependently and when the decision is already taken, if the currenttransaction should be counted or accumulated permanently. Setting “x”(circle 2014, FIG. 20A) is for counting/accumulating when an ARQC isreturned and setting “y” (circle 2062, FIG. 20B) is forcounting/accumulating when a TC is returned.

To give an example of the temporary versus permanent updating of acounter or accumulator, suppose the card/device is offline only andallowed to spend up to a $20 limit (the upper limit). Assume furtherthat $15 has already been spent, and the current transaction is for $6.If “b” is set, the comparison “2” (decision block 2054, FIG. 20B) wouldgive a decline because the current transaction is counted/accumulated(block 2064) before comparing with the limit (15+6>20), setting the bitin the CVR and comparing with the CIAC 2. So with these settings theuser would never spend more than the limit ($20). Now say “b” isn't setbut “y” is set. Then the comparison “2” would give a TC because thecurrent transaction isn't counted before comparing with the limit(15<20), setting the bit in the CVR and comparing with the CIAC2. Butwhen the transaction is consummated, a permanent count/accumulationoccurs and the accumulator value is now 21. So the next time, thetransaction will be declined (it will be necessary to reset the counterto allow more transactions). With these settings the user can spend morethan the $20 limit, but just once. Once the user has spent more, theuser needs to load more money in the payment device.

One feature of the invention allows the issuer to configure the paymentapplication program, for each counter or accumulator, on an individualbasis, whether to temporarily update the counter/accumulator beforechecking any CIAC bit.

According to another feature, the issuer is able to configure thepayment application program, for each counter or accumulator, whether ornot to update the counter/accumulator permanently for TCs or ARQCs.

The logic in the application, with the 4 CIACs and the optionsdescribed, give the issuer a lot of possibilities as to the card riskmanagement that will be done. By just personalizing the applicationdifferently, issuers would have cards behaving differently. An advantageof the solution is that it covers a lot of different behaviors.

In the table shown in FIG. 20C each row of the table shows a differentexample (Examples 1, 2, 3, 4) of definitions of behavior for the paymentapplication program that are possible in accordance with variousembodiments of the invention. The column headings in the tablecorrespond to the setting/configuration bits that were discussed above.Example 2 may be suitable for an “offline only” configuration of thepayment application program. Example 3 may be suitable for a“predominantly offline” configuration of the payment applicationprogram.

Example 1 may be suitable for a card risk management implementation inwhich transactions can be performed offline until a certain limit isreached. Beyond this limit (lower limit), the payment application willattempt to go online to the issuer. If the terminal is offline only,transactions can still be performed offline until a second limit (upperlimit) is reached. Beyond this second limit, transactions have to beapproved online.

Example 4 may be suitable for an online only product in which all thetransactions have to be approved online by the issuer. In thissituation, an accumulator is used to cumulate transactions and when theaccumulated amount exceeds a certain limit (upper limit), transactionsare declined (so the last approved transactions may go beyond the limit,but once the limit is exceeded, transactions are declined). Theaccumulator then has to be reset to zero, for instance by the issuerwith an over-the-air communication or by the user entering the PIN (theaccumulator is then cumulating consecutive transactions done without PINentry—hence the “no CVM” notation in the table of FIG. 20C; this is aprotection against use of a stolen payment device—e.g., if more than say$25 is spent, the PIN has to be entered).

There are many other possible configurations besides those reflected inthe table of FIG. 20C.

FIG. 21 is a flow chart that illustrates yet another process that may beimplemented in the payment-enabled mobile telephone 102 according toaspects of the present invention. The process of FIG. 21 may provide theadvantage of allowing payment card account issuers to enforce arequirement that the user change his/her PIN before first use of thepayment-enabled mobile telephone 102 for a payment or purchasetransaction.

The process of FIG. 21 may idle at decision block 2102 until thepayment-enabled mobile telephone 102 detects that the user has tappedthe payment-enabled mobile telephone 102 on the proximity readercomponent. Once this occurs, the process may advance from decision block2102 to decision block 2104. At decision block 2104, the paymentapplication program may read a relevant status flag, or may otherwisedetermine whether the status of the payment application program is suchthat the user is required to change his/her PIN. If such is not thecase, then the process may advance from decision block 2104 to block2106. At block 2106, the transaction may be handled in a normal manner,as for example described above in connection with one or more of theprevious flow chart drawings.

However, if at decision block 2104 the payment application programdetermines that the user is required to change his/her PIN, then block2108 follows decision block 2104. At block 2108, the payment-enabledmobile telephone 102 may display a prompt to the user to change his/herPIN; the same prompt may indicate that the transaction is beingdeclined.

Decision block 2110 follows block 2108. At decision block 2110, thepayment-enabled mobile telephone 102 determines whether the user hasselected a function on the payment-enabled mobile telephone 102 by whichthe user is able to change his/her PIN. If so, the process advances fromdecision block 2110 to block 2112. At block 2112 the user operates thepayment-enabled mobile telephone 102 so as to execute the PIN-changefunction. This function itself may be provided according to knowntechniques.

Following block 2112 is block 2114. At block 2114 the paymentapplication program may clear the flag that requires the user to changehis/her PIN. The payment-enabled mobile telephone 102 is now usable fora payment/purchase transaction. Accordingly the process of FIG. 21, ifundertaken again, will advance through decision blocks 2102 and 2104 tonormal transaction handling at block 2106. This will not be the case ifthe user does not select the PIN-change function at decision block 2110.

FIG. 22 is a flow chart that illustrates a process that may be performedin the POS terminal 106/proximity reader component 104 in accordancewith aspects of the present invention. FIGS. 23A and 23B are companionsto FIG. 22 in that FIGS. 23A and 23B show a process that may beperformed in accordance with aspects of the present invention in thepayment-enabled mobile telephone 102 in conjunction with the POSterminal process of FIG. 22.

FIGS. 22 and 23 relate to a joint process whereby the POS terminaldetermines that a CVM process should be performed by the payment-enabledmobile telephone 102. This may occur for example in connection with riskmanagement rules embodied in the POS terminal (and established by theretailer's acquiring FI) relating to high value transactions.

At decision block 2202 in FIG. 22, the POS terminal 106/proximity readercomponent 104 determines whether a contactless payment device (possiblya payment-enabled mobile device) has been tapped on the proximity readercomponent 104. If so, the process of FIG. 22 advances from decisionblock 2202 to block 2204. At block 2204, and from the exchange ofcommunications resulting from the “tap”, the POS terminal 106/proximityreader component 104 receives a report from the payment deviceconcerning what capabilities for cardholder verification the paymentdevice has. If the payment device is a conventional contactless paymentcard, it may report that it has no cardholder verification capabilities.However, if the payment device is the payment-enabled mobile telephone102, it may report that it stores a PIN and includes a numeric keypad orthe equivalent and thus is capable of performing a PIN entry andverification for purposes of cardholder verification.

At decision block 2206, the POS terminal 106/proximity reader component104 may determine whether cardholder verification is required for thecurrent transaction. For example, the POS terminal 106/proximity readercomponent 104 may determine whether the transaction is considered a highvalue transaction requiring cardholder verification. If not, the processadvances from decision block 2206 to block 2208. At block 2208, thetransaction proceeds without cardholder verification, or at leastwithout any cardholder verification being required by the POS terminal.In this case, for example, the transaction may be consummated via theexchange of communications arising in the “tap” detected at decisionblock 2202.

Considering again decision block 2206, if the POS terminal is requiringcardholder verification, then the process of FIG. 22 advances fromdecision block 2206 to block 2210. At block 2210, the POS terminal106/proximity reader component 104 instructs the payment-enabled mobiletelephone 102 to perform CVM. (This depiction of the process assumesthat the payment device has indicated that it has cardholderverification capabilities.)

Following block 2210, the process of FIG. 22 idles at decision block2212 until the payment device is tapped once more on the proximityreader component 104. Once this occurs, the process advances fromdecision block 2212 to decision block 2214. At decision block 2214, thePOS terminal 106/proximity reader component 104 determines whether adigital signature received from the payment-enabled mobile telephone 102during the “second tap” exchange of communications indicates that thepayment-enabled mobile telephone 102 has successfully performed therequired cardholder verification process. If so, then the POS terminal106/proximity reader component 104 completes consummation of thetransactions, as indicated at block 2216. However, if the digitalsignature from the payment-enabled mobile telephone 102 does notindicate that the payment-enabled mobile telephone 102 has successfullyperformed the cardholder verification process, then the POS terminaldeclines the transaction, as indicated at block 2218.

Referring now to FIG. 23, the process of FIG. 23 idles at decision block2302 until the payment-enabled mobile telephone 102 detects that it hasbeen tapped on the proximity reader component 104. Once this occurs, theprocess advances from decision block 2302 to block 2304. At block 2304,the payment-enabled mobile telephone 102 reports its cardholderverification capabilities to the proximity reader component 104 asdescribed above in connection with block 2204 in FIG. 22.

Continuing to refer to FIG. 23, decision block 2306 follows block 2304.At decision block 2306, the payment application program in thepayment-enabled mobile telephone 102 determines whether the POS terminalis requiring cardholder verification. If not, then the process advancesto block 2308. At block 2308, the payment-enabled mobile telephone 102proceeds with any risk management process required by the paymentapplication program in the payment-enabled mobile telephone 102 and/orproceeds to consummate the transaction (e.g., as part of thecommunication exchange at the “tap” detected at decision block 2302).

Referring again to decision block 2306, if at this point the paymentapplication program determines that the POS terminal 106/proximityreader component 104 has required the payment-enabled mobile telephone102 to perform cardholder verification, then the process advances toblock 2310. At 2310, the payment-enabled mobile telephone 102 promptsthe user to enter his/her PIN and then verifies the PIN as entered. PINentry and verification may occur as described hereinabove in connectionwith several of the previous flow chart drawings. Next, at decisionblock 2312, the payment application program determines whether the PINentry and verification have been performed successfully. If not, thepayment application may set a flag (block 2314) to indicate failure ofcardholder verification. However, if the PIN entry and verification weresuccessful, then the payment application program may set a flagaccordingly (block 2316).

Following block 2314 or 2316, as the case may be, the process advancesto decision block 2318, at which the process awaits a second tap of thepayment-enabled mobile telephone 102 on the proximity reader component104. Once this takes place, the process advances to block 2320 fromdecision block 2318. At block 2320 the payment application programbuilds a digital signature for the transaction based in part on the flagas set in block 2314 or 2316, as the case may be. At 2322, thepayment-enabled mobile telephone 102 forwards the resulting digitalsignature to the POS terminal 106/proximity reader component 104, forconsideration by the POS terminal 106/proximity reader component 104 asdescribed above in connection with decision block 2214 in FIG. 22. Thedigital signature includes an indication as to whether thepayment-enabled mobile telephone 102 successfully completed cardholderverification. (During the same exchange of communications at the secondtap, the payment-enabled mobile telephone 102 may provide the user'spayment card account number and/or other information to the POS terminal106/proximity reader component 104.)

In some embodiments, the POS terminal 106/proximity reader component 104may not have the capability (assumed to be present for FIGS. 22-23), ofverifying the digital signature generated by the payment applicationprogram in the payment-enabled mobile telephone 102. In suchembodiments, the process of FIGS. 22-23 may be modified. According tothis modification, the payment application program generates acryptographically calculated transaction security code (e.g., a CVC3)that indicates whether or not the payment-enabled mobile telephone 102successfully verified the cardholder. The payment-enabled mobiletelephone 102 transmits the security code to the POS terminal106/proximity reader component 104 as part of the second tap exchange ofcommunications. The POS terminal 106 then passes the security code tothe issuer as part of an authorization request and relies on the issuerto determine whether the security code indicates successful cardholderverification.

In some embodiments of the process of FIGS. 22-23, the requiredcardholder verification may be accomplished by pre-entry of the PIN intothe payment-enabled mobile telephone 102 prior to the first tap, inwhich case the transaction may be consummated and completed via theexchange of communications at the first tap without need for a secondtap.

While many of the above-described risk management processes have beendescribed above apart from others, in practice many or all of theprocesses may be implemented in a single payment application programthat integrates the desired processes. In some embodiments the issuerand/or the user may be permitted to configure the payment applicationprogram so as to determine that one or more of the risk managementprocesses will be implemented by the payment application program fortransaction-related operation of the payment-enabled mobile telephone102. For example, in some embodiments, the issuer may allow PIN entry orACK to be omitted with respect to some transactions, but the user mayelect—and may provide input accordingly into the payment-enabled mobiletelephone 102 to configure the payment application program—that PINentry or ACK be required for such transactions. In other embodiments,the issuer may leave it up to the user's option as to whether the usermay configure the payment application program to permit pre-entry of PINor ACK with respect to certain classes of transactions. Thus, ingeneral, the user may be permitted in some respects to give upconvenience in order to elect for greater risk management security thanthe issuer requires. It should also be noted with respect to the processof FIGS. 22-23 that the merchant's acquiring bank may define the CVMrequirements at the POS terminal, and thus may require risk managementprocedures beyond what the issuer and/or user require.

In some embodiments, the payment card account number is alwaystransmitted from the payment device to the POS terminal at the firsttap, but the transaction may be aborted in some cases if a requiredsecond-tap interaction does not occur. In other embodiments, where asecond tap is required, the payment card account number is transmittedfrom the payment device to the POS terminal only on the second tap.

In some embodiments, a counter may be incremented only for transactionsthat include a transaction amount (e.g., not for transit accesstransactions).

In some embodiments, risk management procedures may require both PIN andACK for some or all transactions.

The payment-enabled mobile telephone (payment application program) maybe configured such that, when a PIN or ACK signal is entered (orpre-entered), the entry/pre-entry remains valid for additionaltransactions. This may be for a predetermined number of additionaltransactions or for additional transactions during a pre-determinedperiod of time (say, the same day). Thus the PIN-verification flag orACK status flag may remain set to accommodate the continuing validity ofthe PIN/ACK entry/pre-entry.

Aspects of the invention have been described above with reference to useof a payment-enabled mobile telephone. Alternatively, however, theprinciples of the invention are also applicable to other types of mobiledevices that store and are at times controlled by a payment applicationprogram. Any and all such devices, including payment-enabled mobiletelephones, should be understood as included in the term“payment-enabled mobile device”.

As used herein and in the appended claims, the term “acceptance entity”refers to a retailer or other organization that operates a proximityreader to read information from a payment-enabled mobile device.

As used herein and in the appended claims, a “currency indicator” is acode or data element that indicates what currency, if any, the currenttransaction is being conducted in. The currency indicator may be a nullindicator that does not indicate a specific currency.

The nonvolatile memory (NVM) referred to herein may be composed of onedevice or of two or more devices.

As used herein and in the appended claims, a program or device is“configurable between” two or more distinct configurations if input maybe provided to the program or device to select between or among theconfigurations.

As used herein and in the appended claims, the term “POS terminal”includes a proximity reader component included in or connected to such aterminal.

As used herein and in the appended claims, “pre-entry” of a PIN or ACKrefers to entry of such a signal prior to the first tap for the currenttransaction of a payment-enabled mobile device on a proximity readercomponent.

Relative to a payment-enabled mobile device and a proximity reader, theterm “tap” refers either to brief physical contact, or relativepositioning such that wireless communication occurs.

As used herein and in the appended claims, the term “computer” should beunderstood to encompass a single computer or two or more computers incommunication with each other.

As used herein and in the appended claims, the term “processor” shouldbe understood to encompass a single processor or two or more processorsin communication with each other.

As used herein and in the appended claims, the term “memory” should beunderstood to encompass a single memory or storage device or two or morememories or storage devices.

The flow charts and descriptions thereof herein should not be understoodto prescribe a fixed order of performing the method steps describedtherein. Rather the method steps may be performed in any order that ispracticable.

As used herein and in the appended claims, the term “payment card systemaccount” includes a credit card account or a deposit account that theaccount holder may access using a debit card. The terms “payment cardsystem account” and “payment card account” are used interchangeablyherein. The term “payment card account number” includes a number thatidentifies a payment card system account or a number carried by apayment card, or a number that is used to route a transaction in apayment system that handles debit card and/or credit card transactions.The term “payment card” includes a credit card or a debit card.

As used herein and in the appended claims, the term “payment cardsystem” refers to a system for handling purchase transactions andrelated transactions and operated under the name of MasterCard, Visa,American Express, Diners Club, Discover Card or a similar system. Insome embodiments, the term “payment card system” may be limited tosystems in which member financial institutions issue payment cardaccounts to individuals, businesses and/or other organizations.

Although the present invention has been described in connection withspecific exemplary embodiments, it should be understood that variouschanges, substitutions, and alterations apparent to those skilled in theart can be made to the disclosed embodiments without departing from thespirit and scope of the invention as set forth in the appended claims.

What is claimed is:
 1. A payment-enabled mobile device, comprising: atleast one mobile device processor comprising a non-volatile memorystoring a first counter and an associated first accumulator used forfinancial risk management purposes prescribed by an issuer of a paymentcard account, and storing a second counter and an associated secondaccumulator used for enforcing a cardholder verification requirement,and storing a payment application program; an antenna; and a transceivercoupled to the antenna and operably coupled to the at least one mobiledevice processor, the transceiver controlled by the at least one mobiledevice processor running the payment application program; wherein thepayment application program includes instructions configured by theissuer of the cardholder's payment card account that causes the mobiledevice processor to: detect when the payment-enabled mobile device istapped on a reader to initiate a current purchase transaction; determinethat the current purchase transaction includes currency other than ahome currency; prompt a user of the payment-enabled mobile device toperform at least one cardholder verification method (CVM); determinethat the CVM is valid; determine that available stored prepaid funds areadequate for the current transaction based on a current value of atleast one of the first accumulator and the first counter; determine thata current value of the second counter and the second accumulator isbelow a lost and stolen risk management limit; reset the second counterand the second accumulator; detect that the mobile device has again beentapped on the reader by the user; and consummate the transaction.
 2. Thepayment-enabled mobile device of claim 1, wherein the instructions fordetermining that the current purchase transaction includes currencyother than a home currency comprises instructions configured to causethe mobile device processor to: receive a currency code associated withthe current purchase transaction; and determine that the currency codematches a second currency different from the home currency of thecardholder.
 3. The payment-enabled mobile device of claim 2, wherein thecurrency code comprises a null indicator, and further comprisinginstructions configured to cause the mobile device processor to:determine that available prepaid funds stored in a memory are adequatefor a current transaction associated with the null indicator based on acurrent value of at least one of the first accumulator and the firstcounter; determine that a current value of the second counter and thesecond accumulator stored in the memory is below a lost and stolen riskmanagement limit; reset the second counter and the second accumulator;detect that the mobile device has again been tapped on the reader by theuser; and consummate the current transaction.
 4. The payment-enabledmobile device of claim 1, further comprising, subsequent to theinstructions for determining that the CVM is valid, instructionsconfigured to cause the mobile device processor to: determine thatavailable prepaid funds stored in the memory are inadequate for acurrent transaction based on a current value of at least one of thefirst accumulator and the first counter; decline the currenttransaction; and prompt the user of the payment-enabled mobile device totop-up the prepaid funds amount.
 5. The payment-enabled mobile device ofclaim 1, further comprising, subsequent to the instructions fordetermining that available prepaid funds stored in a memory are adequatefor the current transaction, instructions configured to cause the mobiledevice processor to: determine that a current value of the secondcounter and the second accumulator exceeds a lost and stolen riskmanagement limit; prompt the user of the payment-enabled mobile deviceto enter a personal identification number (PIN); determine that the PINis valid; reset the second counter and the second accumulator; detectthat the mobile device has again been tapped on the reader by the user;and consummate the current transaction.
 6. The payment-enabled mobiledevice of claim 1, further comprising, subsequent to the instructionsfor prompting the user to perform the at least one cardholderverification method (CVM), instructions configured to cause the mobiledevice processor to: determine that a predetermined time has elapsedwithout performance of the at least one CVM by the user; and decline thecurrent transaction.
 7. A method of operating a payment-enabled mobiledevice comprising: detecting, by a mobile device processor of apayment-enabled mobile device, that the payment-enabled mobile devicehas been tapped on a reader by a user to initiate a current purchasetransaction; determining, by the mobile device processor, that thecurrent purchase transaction includes currency other than a homecurrency; prompting, by the mobile device processor, a user of thepayment-enabled mobile device to perform at least one cardholderverification method (CVM); determining, by the mobile device processor,that the CVM is valid; determining, by the mobile device processor, thatavailable prepaid funds stored in a memory are adequate for a currenttransaction based on a current value of at least one of a firstaccumulator and a first counter; determining, by the mobile deviceprocessor, that a current value of a second counter and a secondaccumulator stored in the memory is below a lost and stolen riskmanagement limit; resetting, by the mobile device processor, the secondcounter and the second accumulator; detecting, by the mobile deviceprocessor, that the mobile device has again been tapped on the reader bythe user; and consummating, by the mobile device processor, the currenttransaction.
 8. The method of claim 7, wherein determining that thecurrent purchase transaction includes currency other than a homecurrency comprises: receiving, by the mobile device processor, acurrency code associated with the current purchase transaction; anddetermining, by the mobile device processor, that the currency codematches a second currency different from the home currency of thecardholder.
 9. The method of claim 8, wherein the currency codecomprises a null indicator, and further comprising: determining, by themobile device processor, that available prepaid funds stored in a memoryare adequate for a current transaction associated with the nullindicator based on a current value of at least one of a firstaccumulator and a first counter; determining, by the mobile deviceprocessor, that a current value of a second counter and a secondaccumulator stored in the memory is below a lost and stolen riskmanagement limit; resetting, by the mobile device processor, the secondcounter and the second accumulator; detecting, by the mobile deviceprocessor, that the mobile device has again been tapped on the reader bythe user; and consummating, by the mobile device processor, the currenttransaction.
 10. The method of claim 7, further comprising, subsequentto determining that the CVM is valid: determining, by the mobile deviceprocessor, that available prepaid funds stored in the memory areinadequate for a current transaction based on a current value of atleast one of the first accumulator and the first counter; declining, bythe mobile device processor, the current transaction; and prompting, bythe mobile device processor, the user of the payment-enabled mobiledevice to top-up the prepaid funds amount.
 11. The method of claim 7,further comprising, subsequent to determining that available prepaidfunds stored in a memory are adequate for the current transaction:determining, by the mobile device processor, that a current value of thesecond counter and the second accumulator exceeds a lost and stolen riskmanagement limit; prompting, by the mobile device processor, the user ofthe payment-enabled mobile device to enter a personal identificationnumber (PIN); determining, by the mobile device processor, that the PINis valid; resetting, by the mobile device processor, the second counterand the second accumulator; detecting, by the mobile device processor,that the mobile device has again been tapped on the reader by the user;and consummating, by the mobile device processor, the currenttransaction.
 12. The method of claim 7, further comprising, afterprompting the user to perform the at least one cardholder verificationmethod (CVM): determining, by the mobile device processor, that apredetermined time has elapsed without performance of the at least oneCVM by the user; and declining, by the mobile device processor, thecurrent transaction.